SonarSource Rules
  • Products

    In-IDE

    Code Quality and Security in your IDE with SonarQube Ide

    IDE extension that lets you fix coding issues before they exist!

    Discover SonarQube for IDE

    SaaS

    Code Quality and Security in the cloud with SonarQube Cloud

    Setup is effortless and analysis is automatic for most languages

    Discover SonarQube Cloud

    Self-Hosted

    Code Quality and Security Self-Hosted with SonarQube Server

    Fast, accurate analysis; enterprise scalability

    Discover SonarQube Server
  • SecretsSecrets
  • ABAPABAP
  • AnsibleAnsible
  • ApexApex
  • AzureResourceManagerAzureResourceManager
  • CC
  • C#C#
  • C++C++
  • CloudFormationCloudFormation
  • COBOLCOBOL
  • CSSCSS
  • DartDart
  • DockerDocker
  • FlexFlex
  • GitHub ActionsGitHub Actions
  • GoGo
  • HTMLHTML
  • JavaJava
  • JavaScriptJavaScript
  • JSONJSON
  • JCLJCL
  • KotlinKotlin
  • KubernetesKubernetes
  • Objective CObjective C
  • PHPPHP
  • PL/IPL/I
  • PL/SQLPL/SQL
  • PythonPython
  • RPGRPG
  • RubyRuby
  • RustRust
  • ScalaScala
  • ShellShell
  • SwiftSwift
  • TerraformTerraform
  • TextText
  • TypeScriptTypeScript
  • T-SQLT-SQL
  • VB.NETVB.NET
  • VB6VB6
  • XMLXML
  • YAMLYAML
Dart

Dart static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your DART code

  • All rules 126
  • Vulnerability4
  • Bug15
  • Security Hotspot8
  • Code Smell99
 
Tags
    Impact
      Clean code attribute
        1. Parameter names should match base declaration

           Code Smell
        2. "child" properties should be placed last in widget instantiation

           Code Smell
        3. Literal constructors parameters of @immutable classes should be const

           Code Smell
        4. Unnecessary widget containers should be removed

           Code Smell
        5. Widget constructors should have a key parameter

           Code Smell
        6. "SizedBox" should be used to add a whitespace to a layout

           Code Smell
        7. Flutter widget "createState" should only return a new "State"

           Code Smell
        8. @immutable classes should only have const constructors

           Code Smell
        9. Const constructors should be invoked with const

           Code Smell
        10. "part of" directives should be used with strings

           Code Smell
        11. Unnecessary getters and setters should be removed

           Code Smell
        12. Web-only libraries should only be used in Flutter web plugins

           Code Smell
        13. Super parameters should be preferred to forwarding parameters to super

           Code Smell
        14. If-null operator shouldn't be used with "null"

           Code Smell
        15. Generic function type syntax should be preferred for parameters

           Code Smell
        16. Unnecessary nullable in final declaration should be removed

           Code Smell
        17. Null-aware assignments should make sense

           Code Smell
        18. "new" keyword shouldn't be used

           Code Smell
        19. Unnecessary use of "toList" with spread operator

           Code Smell
        20. Unnecessary string interpolations

           Code Smell
        21. "late" modifier should be necessary

           Code Smell
        22. Unnamed constructor should be used instead of `.new`

           Code Smell
        23. Initialization formals shouldn't be unnecessarily type annotated

           Code Smell
        24. Unnecessary braces in string interpolation should be removed

           Code Smell
        25. Triple slash should be used for documentation comments

           Code Smell
        26. Initializing formals should be used

           Code Smell
        27. Spread collections should be preferred to chaining list insertions

           Code Smell
        28. Inline list literals should be preferred to chains of insertions

           Code Smell
        29. Referenced packages should be listed as dependencies

           Code Smell
        30. Dependencies should be sorted

           Code Smell
        31. For elements should be preferred to Map.fromIterable

           Code Smell
        32. Adjacent string concatenation should be preferred

           Code Smell
        33. Fields should not be overridden

           Code Smell
        34. Non-constant names should comply with a naming convention

           Code Smell
        35. Library prefixes shouldn't start with underscore

           Code Smell
        36. Private types shouldn't be exposed in public API

           Code Smell
        37. Library prefixes should comply with naming conventions

           Code Smell
        38. Library annotations should be attached to library directive

           Code Smell
        39. Library doc comments should be attached to library directive

           Code Smell
        40. Implementation imports shouldn't be used

           Code Smell
        41. Implicit tearoff of "call" shouldn't be used

           Code Smell
        42. Single cascade shouldn't be used

           Code Smell
        43. Function literals shouldn't be used in foreach calls

           Code Smell
        44. Wildcard variable shouldn't be used

           Code Smell
        45. Relative lib imports should not be used

           Code Smell
        46. Uninitialized variables and fields should be explicitly typed

           Code Smell
        47. Types should not be used as parameter names

           Code Smell
        48. Void functions should not return null

           Code Smell
        49. Function declarations should be preferred over variables

           Code Smell
        50. Extension identifiers should comply with a naming convention

           Code Smell
        51. Local identifiers should not start with underscore

           Code Smell
        52. Null checks in equality operators should be avoided

           Code Smell
        53. If-null operator should be preferred

           Code Smell
        54. Null-aware operators should be preferred

           Code Smell
        55. Unnecessary character escapes should be removed

           Code Smell
        56. Redundant type casts should be removed

           Code Smell
        57. Empty constructor bodies should be replaced with a semicolon

           Code Smell
        58. Generic function type aliases should be preferred

           Code Smell
        59. Type parameters should not shadow other type parameters

           Code Smell
        60. "await" should only be used with futures

           Code Smell
        61. "static final" declarations should be "const" instead

           Code Smell
        62. Cognitive Complexity of functions should not be too high

           Code Smell
        63. "switch" statements should cover all cases

           Code Smell
        64. Interpolation should be used instead of String concatenation

           Code Smell
        65. Ternary operators should not be nested

           Code Smell
        66. Collection literals should be preferred

           Code Smell
        67. Conditional assignment should be preferred

           Code Smell
        68. Iterable "whereType" should be used to filter by type

           Code Smell
        69. "this" should only be used when required

           Code Smell
        70. Fields that are only assigned in the constructor should be "readonly"

           Code Smell
        71. Exceptions should not be ignored

           Code Smell
        72. Variables should not be initialized with "null"

           Code Smell
        73. "is!" should be used instead of "!(. is .)"

           Code Smell
        74. Dart build, compiler, or analyzer configuration errors

           Code Smell
        75. Code annotated as deprecated should not be used

           Code Smell
        76. Unused assignments should be removed

           Code Smell
        77. File names should comply with a naming convention

           Code Smell
        78. Cyclomatic Complexity of functions should not be too high

           Code Smell
        79. Unused local variables should be removed

           Code Smell
        80. Control structures should use curly braces

           Code Smell
        81. Package names should comply with a naming convention

           Code Smell
        82. String literals should not be duplicated

           Code Smell
        83. Overriding methods should do more than simply call the same method in the super class

           Code Smell
        84. "@override" should be used on overriding members

           Code Smell
        85. "isEmpty" or "isNotEmpty" should be used to test for emptiness

           Code Smell
        86. Constant names should comply with a naming convention

           Code Smell
        87. Track uses of "TODO" tags

           Code Smell
        88. Track uses of "FIXME" tags

           Code Smell
        89. Deprecated code should be removed

           Code Smell
        90. Files should end with a newline

           Code Smell
        91. Unnecessary imports should be removed

           Code Smell
        92. Deprecated elements should include explanation

           Code Smell
        93. Utility classes should not have public constructors

           Code Smell
        94. Empty statements should be removed

           Code Smell
        95. Functions should not have too many parameters

           Code Smell
        96. Unused "private" fields should be removed

           Code Smell
        97. Unused labels should be removed

           Code Smell
        98. Standard outputs should not be used directly to log anything

           Code Smell
        99. Class names should comply with a naming convention

           Code Smell

        Initialization formals shouldn't be unnecessarily type annotated

        consistency - conventional
        maintainability
        Code Smell

          Why is this an issue?

          How can I fix it?

          More Info

          In Dart, there’s a concise syntax for constructors with init formals. You can declare a simple class with constructor this way:

          class Person {
          
            String name;
            int age;
          
            Person(this.name, this.age);
          }
          

          By default, the type of the constructor parameter is assumed to be the same as the type of the field. In case of using super.field, the type is assumed to be the type of the parameter in super class constructor. Thus, there’s no need to declare it explicitly.

          Exceptions

          The rule doesn’t apply if the type of the parameter is different. This should be declared explicitly:

          class Parent {
            Iterable<String> children;
          
            Parent(this.children);
          }
          
          class Person extends Parent {
            Person(List<String> super.children); // Compliant, because the type is different
          }
          
            Available In:
          • SonarQube CloudDetect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories
          • SonarQube ServerAnalyze code in your
            on-premise CI
            Developer Edition
            Available Since
            10.8

          © 2008-2025 SonarSource SA. All rights reserved.

          Privacy Policy | Cookie Policy | Terms of Use